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Abstract 


The WebSocket protocol enables two-way real-time communication 
between clients and servers in situations where direct access to TCP 
and UDP is not available (for example, from within JavaScript in a 
web browser). This document specifies a new WebSocket subprotocol as 
a reliable transport mechanism between Message Session Relay Protocol 
(MSRP) clients and relays to enable usage of MSRP in new scenarios. 
This document normatively updates RFCs 4975 and 4976. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7977. 
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Les 


Introduction 


The WebSocket [RFC6455] protocol enables message exchange between 
clients and servers on top of a persistent TCP connection (optionally 
secured with Transport Layer Security (TLS) [RFC5246]). The initial 
protocol handshake makes use of HTTP [RFC7230] semantics, allowing 
the WebSocket protocol to reuse existing HTTP infrastructure. 


Modern web browsers include a WebSocket client stack complying with 
the WebSocket API [WS-API] as specified by the W3C. It is expected 
that other client applications (those running in personal computers 
and devices such as smartphones) will also make a WebSocket client 
Stack available. The specification in this document enables usage of 
Message Session Relay Protocol [RFC4975] in these scenarios. 


This specification defines a new WebSocket subprotocol (as defined in 
Section 1.9 in [RFC6455]) for transporting MSRP messages between a 
WebSocket client and MSRP relay [RFC4976] containing a WebSocket 
Server, a new transport for MSRP, and procedures for MSRP clients and 
relays implementing the WebSocket transport. 


MSRP over WebSocket is well suited for MSRP interactions between 
clients and servers. Common use cases for MSRP over WebSocket 
include: 


o Human-to-machine messaging 


o Client-to-server data exchange (for example, application control 
signaling) 


o Human-to-human messaging where local policy requires 
authentication and/or logging 


MSRP Connection Establishment for Media Anchoring (MSRP-CEMA) 
[RFC6714] is outside of the scope of this document, as this document 
is intended to describe connecting to a WebSocket server that is an 
MSRP relay. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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2.1. Definitions 


MSRP WebSocket Client: An MSRP entity capable of opening outbound 
connections to MSRP relays that are WebSocket servers and 
communicating using the WebSocket MSRP subprotocol as defined 
by this document. 


MSRP WebSocket Server: An MSRP entity (specifically an MSRP relay 
[RFC4976]) capable of listening for inbound connections from 
WebSocket clients and communicating using the WebSocket MSRP 
subprotocol as defined by this document. 


3. WebSocket Protocol Overview 


The WebSocket protocol [RFC6455] is a transport layer on top of TCP 
(optionally secured with TLS [RFC5246]) in which both the client and 
Server exchange message units in both directions. The protocol 
defines a connection handshake, WebSocket subprotocol and extensions 
negotiation, a frame format for sending application and control data, 
a masking mechanism, and status codes for indicating disconnection 
causes. 


The WebSocket connection handshake is based on HTTP [RFC7230] and 
utilizes the HTTP GET method with an "Upgrade" request. This is sent 
by the client and then answered by the server (if the negotiation 
succeeded) with an HTTP 101 status code. Once the handshake is 
completed, the connection upgrades from HTTP to the WebSocket 
protocol. This handshake procedure is designed to reuse the existing 
HTTP infrastructure. During the connection handshake, client and 
server agree on the application protocol to use on top of the 
WebSocket transport. Such application protocol (also known as a 
"WebSocket subprotocol") defines the format and semantics of the 
messages exchanged by the endpoints. This could be a custom protocol 
or a standardized one (such as the WebSocket MSRP subprotocol defined 
in this document). Once the HTTP 101 response is processed, both 
client and server reuse the underlying TCP connection for sending 
WebSocket messages and control frames to each other. Unlike plain 
HTTP, this connection is persistent and can be used for multiple 
message exchanges. 


WebSocket defines message units to be used by applications for the 
exchange of data, so it provides a message boundary-preserving 
transport layer. These message units can contain either UTF-8 text 
or binary data and can be split into multiple WebSocket text/binary 
transport frames as needed by the WebSocket stack. 
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The WebSocket API [WS-API] for web browsers only defines callbacks to 
be invoked upon receipt of an entire message unit regardless of 
whether it was received in a single WebSocket frame or split across 
multiple frames. 


4. The WebSocket MSRP Subprotocol 


The term WebSocket subprotocol refers to an application-level 
protocol layered on top of a WebSocket connection. This document 
specifies the WebSocket MSRP subprotocol for carrying MSRP requests 
and responses through a WebSocket connection. 


4.1. Handshake 


The MSRP WebSocket Client and MSRP WebSocket Server negotiate usage 
of the WebSocket MSRP subprotocol during the WebSocket handshake 
procedure as defined in Section 1.3 of [RFC6455]. The Client MUST 
include the value "msrp" in the Sec-WebSocket-Protocol header in its 
handshake request. The 101 reply from the Server MUST contain "msrp" 
in its corresponding Sec-WebSocket-Protocol header. 


Below is an example of a WebSocket handshake in which the Client 
requests the WebSocket MSRP subprotocol support from the Server: 


GET / HTTP/1.1 

Host: a.example.com 

Upgrade: websocket 

Connection: Upgrade 

Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZzQ-- 
Origin: http://www.example.com 
Sec-WebSocket-Protocol: msrp 
Sec-WebSocket-Version: 13 


The handshake response from the Server accepting the WebSocket MSRP 
subprotocol would look as follows: 


HTTP/1.1 101 Switching Protocols 

Upgrade: websocket 

Connection: Upgrade 

Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK-*xOo- 
Sec-WebSocket-Protocol: msrp 


Once the negotiation has been completed, the WebSocket connection is 
established and can be used for the transport of MSRP requests and 
responses. The WebSocket messages transmitted over this connection 
MUST conform to the negotiated WebSocket subprotocol. 
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4.2. MSRP Encoding 


WebSocket messages can be transported in either UTF-8 text frames or 
binary frames. MSRP [RFC4975] allows both text and binary bodies in 
MSRP requests. Therefore, MSRP WebSocket Clients and Servers MUST 
accept both text and binary frames. 


The WebSocket API [WS-API] does not allow developers to choose 
whether to send UTF-8 text or binary frames but will not send 
non-UTF-8 characters in a text frame. The content of text frames 
MUST be interpreted as binary by WebSocket Clients and Servers. 


5. MSRP WebSocket Transport 
5.1. General 


WebSocket clients cannot receive WebSocket connections initiated by 
other WebSocket clients or WebSocket servers. This means that it is 
challenging for an MSRP client to communicate directly with other 
MSRP clients. Therefore, all MSRP-over-WebSocket messages MUST be 
routed via an MSRP WebSocket Server. MSRP traffic transported over 
WebSockets MUST be protected by using a Secure WebSocket (WSS) 
connection (using TLS [RFC5246] over TCP). 


MSRP WebSocket Servers can be used to route MSRP messages between 
MSRP WebSocket Clients and between MSRP WebSocket Clients and 
"normal" MSRP clients and relays. 


Each MSRP chunk MUST be carried within a single WebSocket message, 
and a WebSocket message MUST NOT contain more than one MSRP chunk. 


This simplifies parsing of MSRP messages for both clients and 
servers. When large messages are sent by a non-WebSocket peer, MSRP 
chunking (as defined in Section 5.1 of [RFC4975]) MUST be used by the 
WebSocket MSRP Servers to split the message into several smaller MSRP 
chunks. 


5.2. Updates to RFC 4975 
5.2.1. MSRP URI Transport Parameter 
This document defines the value "ws" as the transport parameter value 


for an MSRP URI [RFC3986] to be contacted using the MSRP WebSocket 
subprotocol as transport. 
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The updated ABNF [RFC5234] for this parameter is the following (the 
original BNF for this parameter can be found in [RFC4975]): 


transport = "tcp" / "ws" / 1*ALPHANUM 
5.2.2. SDP Transport Protocol 


This document does not define a new Session Description Protocol 
(SDP) transport protocol for MSRP over WebSockets. As all MSRP-over- 
WebSocket messages MUST be routed via an MSRP WebSocket Server, the 
MSRP WebSocket Client MUST specify "TCP/TLS/MSRP" protocols in the 
SDP m-line -- that being the protocol used by non-WebSocket clients 
and between MSRP relays (see Section 8.1 of [RFC4975]). 


The "ws" transport parameter will appear in the endpoint URI in the 
SDP "path" attribute (see Section 8.2 of [RFC4975]). MSRP was 
designed with the possibility of new transport bindings in mind (see 
Section 6 of [RFC4975]), so MSRP implementations are expected to 
allow unrecognized transports, provided that they do not have to 
establish a direct connection to the resource described by the URI. 


5.3. Updates to RFC 4976 
5.3.1. AUTH Request Authentication 


The MSRP relay specification [RFC4976] states that AUTH requests MUST 
be authenticated. This document modifies this requirement to state 
that all connections between MSRP clients and relays MUST be 
authenticated. In the case of the MSRP WebSocket Clients, there are 
three possible authentication mechanisms: 


1. HTTP Digest authentication in AUTH (as per [RFC4976]). 


2. Cookie-based or HTTP Digest authentication in the WebSocket 
Handshake (see Section 7). 


3. Mutual TLS between the WebSocket-based MSRP client and the 
WebSocket server. 


The AUTH request is a required event when authentication occurs at 
the WebSocket connection level since the "Use-Path:" header required 
to create the SDP offer is included in the 200 OK response to the 
AUTH request. 
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6. 


Connection Keepalive 


It is RECOMMENDED that MSRP WebSocket Clients and Servers keep their 
WebSocket connections open by sending periodic WebSocket "Ping" 
frames as described in Section 5.5.2 of [RFC6455]. 


The WebSocket API [WS-API] does not provide a mechanism for 
applications running in a web browser to control whether or not 
periodic WebSocket "Ping" frames are sent to the server. The 
implementation of such a keepalive feature is the decision of each 
web browser manufacturer and may also depend on the configuration of 
the web browser. 


A future WebSocket protocol extension providing a similar keepalive 
mechanism could also be used. 


When MSRP WebSocket Clients or Servers cannot use WebSocket "Ping" 
frames to keep connections open, an MSRP implementation MAY use 
bodiless SEND requests as described in Section 7.1 of [RFC4975]. 
MSRP WebSocket Clients or Servers MUST be prepared to receive 
bodiless SEND requests. 


Authentication 


Prior to sending MSRP requests, an MSRP WebSocket Client connects to 
an MSRP WebSocket Server and performs the connection handshake. As 
described in Section 3, the handshake procedure involves a HTTP GET 
method request from the Client and a response from the Server 
including an HTTP 101 status code. 


In order to authorize the WebSocket connection, the MSRP WebSocket 
Server MAY inspect any HTTP headers present (for example, Cookie 
[RFC6265], Host [RFC7230], or Origin [RFC6454]) in the HTTP GET 
request. For many web applications, the value of such a Cookie is 
provided by the web server once the user has authenticated themselves 
to the web server, which could be done by many existing mechanisms. 
As an alternative method, the MSRP WebSocket Server could request 
HTTP authentication by replying to the Client's GET method request 
with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers 
this usage in Section 4.1 and is paraphrased as follows: 


If the status code received from the server is not 101, the 
WebSocket client stack handles the response per HTTP [RFC7230] 
procedures; in particular, the client might perform authentication 
if it receives a 401 status code. 
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If the HTTP GET request contains an Origin header, the MSRP WebSocket 
Server SHOULD indicate Cross-Origin Resource Sharing [CORS] by adding 
an Access-Control-Allow-Origin header to the 101 response. 


Regardless of whether the MSRP WebSocket Server requires 
authentication during the WebSocket handshake, authentication MAY be 
requested at the MSRP protocol level by an MSRP Server challenging 
AUTH requests using a 401 response. Therefore, an MSRP WebSocket 
Client SHOULD support HTTP Digest [RFC7235] authentication as stated 
in [RFC4976]. 


8. Examples 
8.1. Authentication 
8.1.1. WebSocket Authentication 
Alice (MSRP WSS) a.example.com 


[HTTP GET (WS handshake) F1 | 


€— >| 
101 Switching Protocols F2 | 
< a a ee eg eS a a ee eS ey ee ee ee ee ee Cree ay 
| | 
|AUTH F3 | 
——————————ÉÁ (€: > | 
|200 OK F4 | 


Alice loads a web page using her web browser and retrieves JavaScript 
code implementing the WebSocket MSRP subprotocol defined in this 
document. The JavaScript code (an MSRP WebSocket Client) establishes 
a secure WebSocket connection with an MSRP relay (an MSRP WebSocket 
Server) at a.example.com. Upon WebSocket connection, Alice 
constructs and sends an MSRP AUTH request. Since the JavaScript 
stack in a browser has no way to determine the local address from 
which the WebSocket connection was made, this implementation uses a 
random ".invalid" domain name for the hostpart of the From-Path URI 
(see Appendix A). 
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In this example, it is assumed that authentication is performed at 
the WebSocket layer (not shown), so no challenge is issued for the 
MSRP AUTH message: 


F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS) 


GET / HTTP/1.1 

Host: a.example.com 

Upgrade: websocket 

Connection: Upgrade 

Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ-- 
Origin: https://www.example.com 
Sec-WebSocket-Protocol: msrp 
Sec-WebSocket-Version: 13 


F2 101 Switching Protocols a.example.com -» Alice (TLS) 


HTTP/1.1 101 Switching Protocols 

Upgrade: websocket 

Connection: Upgrade 

Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK-*xOo- 
Sec-WebSocket-Protocol: msrp 


F3 AUTH Alice -> a.example.com (transport WSS) 


MSRP 49fi AUTH 
To-Path: msrps://alice@a.example.com:443;ws 
From-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 


F4 200 OK a.example.com -> Alice (transport WSS) 


MSRP 49fi 200 OK 

To-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 
From-Path: msrps://alice@a.example.com:443;ws 
Use-Path: msrps://a.example.com:2855/jui787s2f;tcp 
Expires: 900 
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8.1.2. MSRP Authentication 


Alice (MSRP WSS) a.example.com 


[HTTP GET (WS handshake) F1 | 


€—— >| 
[101 Switching Protocols F2 | 
€—— | 
m F3 | 
|---------------------------- >| 
|401 Unauthorized F4 
|<----------22----2---------- | 
|AUTH F5 | 
SOE EE EE >| 
200 OK F6 

<————— MMMM 


This example uses the same scenario as Section 8.1.1 but with 
authentication performed at the MSRP layer. 


Note that MSRP does not permit line folding. A "\" in the examples 
shows a line continuation due to limitations in line length of this 
document. Neither the backslash nor the extra CRLF is included in 
the actual MSRP message. 


F1 HTTP GET (WS handshake) Alice -> a.example.com (TLS) 


GET / HTTP/1.1 

Host: a.example.com 

Upgrade: websocket 

Connection: Upgrade 

Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ-- 
Origin: https://www.example.com 
Sec-WebSocket-Protocol: msrp 
Sec-WebSocket-Version: 13 


F2 101 Switching Protocols a.example.com -» Alice (TLS) 


HTTP/1.1 101 Switching Protocols 

Upgrade: websocket 

Connection: Upgrade 

Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK-*xOo- 
Sec-WebSocket-Protocol: msrp 
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F3 AUTH Alice -> a.example.com (transport WSS) 


MSRP 4rsxt9nz AUTH 

To-Path: msrps://alice@a.example.com: 443; ws 
From-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 
CRDI 4rsxt9nz$ 


F4 401 Unauthorized a.example.com -» Alice (transport WSS) 


MSRP 4rsxt9nz 401 Unauthorized 

To-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 
From-Path: msrps://alice@a.example.com:443;ws 

WWW-Authenticate: Digest realm-"example.com", \ 
nonce-"UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4-«dd4A-", qop="auth" 
ixi ir 4rsxt9nz$ 


F5 AUTH Alice -> a.example.com (transport WSS) 


MSRP qylhsow5 AUTH 

To-Path: msrps://alice@a.example.com: 443; ws 

From-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 

Authorization: Digest username="alice", realm="example.com", \ 
nonce-"UvtfpVL7XnnJ63EE244fXDthfLihlMHOY4-*dd4A-", \ 
uri="msrps://alice@a.example.com:443;ws", \ 
response="5011d0d58fe975e0d0cdc007ae26f4b7", \ 

gop=auth, cnonce-"zic5ml401prb", nc=00000001 

MEM qylhsow5$ 


F6 200 OK a.example.com -» Alice (transport WSS) 


MSRP qylhsow5 200 OK 

To-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 
From-Path: msrps://alice@a.example.com:443;ws 
Use-Path: msrps://a.example.com:2855/jui787s2f;tcp 
Expires: 900 

ini RET qylhsow5$ 
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8.2. Example Session: MSRP WebSocket Client to MSRP Client 


The following subsections show various message exchanges occurring 
during the course of an MSRP session between a WebSocket client and a 
non-WebSocket client. 


8.2.1. SDP Exchange 


The following example shows SDP that could be included in a SIP 
message to set up an MSRP session between Alice and Bob where Alice 
uses a WebSocket MSRP relay and Bob uses a traditional MSRP client 
without a relay. 


A "N" in the examples shows a line continuation due to limitations in 
line length of this document. Neither the backslash nor the extra 
CRLF is included in the actual SDP. 


Alice makes an offer with a path including the relay (having already 
successfully authenticated with the relay): 


C-IN IP4 a.example.com 

m-message 1234 TCP/TLS/MSRP * 

a=accept-types:message/cpim text/plain text/html 

a-path:msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://df7jal231s0d.invalid:2855/98cjs;ws 


In this offer, Alice wishes to receive MSRP messages via the relay at 
a.example.com. She wants to use TLS as the transport for the MSRP 
session (beyond the relay). She can accept message/cpim, text/plain, 
and text/html message bodies in SEND requests. 


Bob's answer to this offer could look like: 


C-IN IP4 bob.example.com 

m-message 1234 TCP/TLS/MSRP * 
a-accept-types:message/cpim text/plain 
a-path:msrps://bob.example.com:49154/foo;tcp 


Here, Bob wishes to receive the MSRP messages at bob.example.com. He 
can accept only message/cpim and text/plain message bodies in SEND 
requests and has rejected the text/html content offered by Alice. He 
does not need a relay to set up the MSRP session. 
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8.2.2. SEND (MSRP WebSocket Client to MSRP Client) 


Alice (MSRP WSS) a.example.com (MSRP TLS) Bob 
| | 
[SEND F1 | | 
|---------------------------- >| | 
[200 OK F2 | | 
|<---------------------------- | | 

SEND F3 

Mi ieu fie a dumis Qus Vie, a Pn gt ui. iei uis Quei "ai a egi ui pi es Sa i td > 
| |200 OK F4 | 
| [K sta | 
Later in the session, Alice sends an instant message to Bob. The 


MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing 
the message to Bob over TLS. 


Message details (A "\" in the examples shows a line continuation due 
to limitations in line length of this document. Neither the 
backslash nor the extra CRLF is included in the actual request or 
response): 


F1 SEND Alice -> a.example.com (transport WSS) 


MSRP 6aef SEND 

To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://bob.example.com:49154/foo;tcp 
From-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 
Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


F2 200 OK a.example.com -» Alice (transport WSS) 
MSRP 6aef 200 OK 


To-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 
From-Path: msrps://a.example.com:2855/jui787s2f;tcp 
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F3 SEND a.example.com -> Bob (transport TLS) 


MSRP juh76 SEND 

To-Path: msrps://bob.example.com:49154/foo;tcp 

From-Path:  msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://df7jal231s0d.invalid:2855/98cjs;ws 

Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


Hi Bob, I'm about to send you file.mpeg 


F4 200 OK Bob -> a.example.com (transport TLS) 
MSRP juh76 200 OK 


To-Path: msrps://a.example.com:2855/jui787s2f;tcp 
From-Path: msrps://bob.example.com:49154/foo;tcp 


8.2.3. SEND (MSRP Client to MSRP WebSocket Client) 


Bob (MSRP TLS) a.example.com (MSRP WSS) Alice 
| | 
[SEND F1 | | 
Gea Caci iea ya cap uai quis Uum nci oni Rp VaN vais aai Von iue ees Mmi ndi ee Cm qub VR aa ges eed unas > 
200 OK F2 
RAR Stare Ae ie eae | | 
| |SEND F3 | 
| ae quc R DEO >| 
| |200 OK F4 | 
| [Se ee | 
Later in the session, Bob sends an instant message to Alice. The 


MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing 
the message to Alice over secure WebSocket. 
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Message details (A "\" in the examples shows a line continuation due 
to limitations in line length of this document. Neither the 
backslash nor the extra CRLF is included in the actual request or 
response): 


Fl SEND Bob -> a.example.com (transport TLS) 


MSRP xght6 SEND 

To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://df7jal231s0d.invalid:2855/98cjs;ws 
From-Path: msrps://bob.example.com:49154/foo;tcp 
Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


Thanks for the file. 


F2 200 OK a.example.com -> Bob (transport TLS) 


MSRP xght6 200 OK 
To-Path: msrps://bob.example.com:49154/foo;tcp 
From-Path: msrps://a.example.com:2855/jui787s2f;tcp 


F3 SEND a.example.com -» Alice (transport WSS) 


MSRP yh67 SEND 

To-Path:  msrps://df7jal231s0d.invalid:2855/98cjs;ws 

From-Path:  msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://bob.example.com:49154/foo;tcp 

Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


Thanks for the file. 
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F4 200 OK Alice -> a.example.com (transport WSS) 


MSRP yh67 200 OK 
To-Path:  msrps://a.example.com:2855/jui787s2f;tcp 
From-Path:  msrps://df7jal231s0d.invalid:2855/98cjs;ws 


8.3. Example Session: Two MSRP WebSocket Clients 


The following subsections show various message exchanges occurring 
during the course of an MSRP session between two WebSocket clients. 


8.3.1. SDP Exchange 


The following example shows SDP that could be included in a SIP 
message to set up an MSRP session between Alice and Carol where both 
of them are using the same WebSocket MSRP relay. 


Alice makes an offer with a path including the relay (having already 
successfully authenticated with the relay): 


C-IN IP4 a.example.com 

m-message 1234 TCP/TLS/MSRP * 

a=accept-types:message/cpim text/plain text/html 

a-path:msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://df7jal231s0d.invalid:2855/98cjs;ws 


In this offer, Alice wishes to receive MSRP messages via the relay at 
a.example.com. She wants to use TLS as the transport for the MSRP 
session (beyond the relay). She can accept message/cpim, text/plain, 
and text/html message bodies in SEND requests. 


Carol's answer to this offer could look like: 


C-IN IP4 a.example.com 

m-message 1234 TCP/TLS/MSRP * 

a-accept-types:message/cpim text/plain 

a-path:msrps://a.example.com:2855/iwnslt;tcp \ 
msrps://jk9awpl4vj8x.invalid:2855/76qwe;ws 


Here, Carol also wishes to receive the MSRP messages via 
a.example.com. She can accept only message/cpim and text/plain 
message bodies in SEND requests and has rejected the text/html 
content offered by Alice. 
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8. 


3 


«24 SEND 
Alice (MSRP WSS) a.example.com (MSRP WSS) Carol 
| | 
[SEND F1 | | 
|---------------------------- d | 
[200 OK F2 | | 
|<---------------------------- | | 
SEND F3 
— ae ee E E —— Re —— À E, > 
| |200 OK F4 | 
| [<---------------------------- | 
Later in the session, Alice sends an instant message to Carol. The 


MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing 
the message to Carol over secure WebSocket. 


In this example, both Alice and Carol are using MSRP WebSocket 
Clients and the same MSRP WebSocket Server. This means that 
a.example.com will appear twice in the To-Path in Fl. a.example.com 
can either handle this internally or loop the MSRP SEND request back 
to itself as if it were two separate MSRP relays. 


Message details (A "\" in the examples shows a line continuation due 
to limitations in line length of this document. Neither the 
backslash nor the extra CRLF is included in the actual request or 
response): 


F1 SEND Alice -> a.example.com (transport WSS) 


MSRP kjh6 SEND 

To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://a.example.com:2855/iwnslt;tcp \ 
msrps://jk9awpl4vj8x.invalid:2855/76qwe;ws 

From-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 

Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


Carol, I sent that file to Bob. 
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F2 200 OK a.example.com -» Alice (transport WSS) 


MSRP kjh6 200 OK 
To-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 
From-Path: msrps://a.example.com:2855/jui787s2f;tcp 


F3 SEND a.example.com -» Carol (transport WSS) 


MSRP re58 SEND 

To-Path: msrps://jk9awpl4vj8x.invalid:2855/76qwe;ws 

From-Path: msrps://a.example.com:2855/iwnslt;tcp \ 
msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://df7jal231s0d.invalid/98cjs;ws 

Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


Carol, I sent that file to Bob. 


F4 200 OK Carol -> a.example.com (transport WSS) 


MSRP re58 200 OK 
To-Path: msrps://a.example.com:2855/iwnslt;tcp 
From-Path: msrps://jk9awpl4vj8x.invalid:2855/76qwe;ws 


8.4. Example Session: MSRP WebSocket Client to MSRP Client Using a 
Relay 


The following subsections show various message exchanges occurring 
during the course of an MSRP session between a WebSocket client and a 
non-WebSocket client, where the latter is also using an MSRP relay. 


8.4.1. SDP Exchange 


The following example shows SDP that could be included in a SIP 
message to set up an MSRP session between Alice and Bob where Alice 
uses a WebSocket MSRP relay and Bob uses a traditional MSRP client 
with a separate relay. 
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Alice makes an offer with a path including the relay (having already 
successfully authenticated with the relay): 


C-IN IP4 a.example.com 

m-message 1234 TCP/TLS/MSRP * 

a=accept-types:message/cpim text/plain text/html 

a-path:msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://df7jal231s0d.invalid:2855/98cjs;ws 


In this offer, Alice wishes to receive MSRP messages via the relay at 
a.example.com. She wants to use TLS as the transport for the MSRP 
session (beyond the relay). She can accept message/cpim, text/plain, 
and text/html message bodies in SEND requests. 


Bob's answer to this offer could look like: 


C-IN IP4 bob.example.com 

m-message 1234 TCP/TLS/MSRP * 

a-accept-types:message/cpim text/plain 

a=path:msrps://relay.example.net:2855/kwvin5f;tcp \ 
msrps://bob.example.com:49154/foo;tcp 


Here, Bob wishes to receive the MSRP messages via the relay at 
relay.example.net. He can accept only message/cpim and text/plain 
message bodies in SEND requests and has rejected the text/html 
content offered by Alice. 


8.4.2. | SEND 


Alice (MSRP WSS) a.example.com (MSRP) relay.example.net (MSRP) Bob 
| | | | 
[SEND F1 | | | 
--------------------- >| | | 
200 OK F2 

ee | | | 
| | SEND F3 | | 
| | ---------------------- >| | 
| |200 OK F4 | | 
| |«----—---—---------- | | 

SEND F5 

| ee > 
| | |200 OK F6 | 
| | | <-----------~------- | 


Later in the session, Alice sends an instant message to Bob. The 
MSRP WebSocket Server at a.example.com acts as an MSRP relay, routing 
the message to Bob via his relay, relay.example.net. 
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Message details (A "\" in the examples shows a line continuation due 
to limitations in line length of this document. Neither the 
backslash nor the extra CRLF is included in the actual request or 
response): 


F1 SEND Alice -> a.example.com (transport WSS) 


MSRP Ycwt SEND 

To-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://relay.example.net:2855/kwvin5f;tcp \ 
msrps://bob.example.com:49154/foo;tcp 

From-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 

Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


F2 200 OK a.example.com -» Alice (transport WSS) 


MSRP Ycwt 200 OK 
To-Path: msrps://df7jal231s0d.invalid:2855/98cjs;ws 
From-Path: msrps://a.example.com:2855/jui787s2f;tcp 


F3 SEND a.example.com -> relay.example.net (transport TLS) 


MSRP 13GA SEND 

To-Path: msrps://relay.example.net:2855/kwvin5f;tcp \ 
msrps://bob.example.com:49154/foo;tcp 

From-Path: msrps://a.example.com:2855/jui787s2f;tcp \ 

msrps://df7jal231s0d.invalid/98cjs;ws 

Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


Bob, that was the wrong file - don't watch it! 
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F4 200 OK relay.example.net -> a.example.com (transport TLS) 


MSRP 13GA 200 OK 
To-Path: msrps://a.example.com:2855/iwnslt;tcp 
From-Path: msrps://relay.example.net:2855/kwvinb5f;tcp 


F5 SEND relay.example.net -> bob.example.com (transport TLS) 


MSRP kXeg SEND 

To-Path: msrps://bob.example.com:49154/foo;tcp 

From-Path: msrps://relay.example.net:2855/kwvin5f;tcp \ 
msrps://a.example.com:2855/jui787s2f;tcp \ 
msrps://df7jal231s0d.invalid/98cjs;ws 

Success-Report: no 

Byte-Range: 1-*/* 

Message-ID: 87652 

Content-Type: text/plain 


F6 200 OK bob.example.com -> relay.example.net (transport TLS) 
MSRP kXeg 200 OK 


To-Path: msrps://relay.example.net:2855/kwvin5f;tcp 
From-Path: msrps://bob.example.com:49154/foo;tcp 
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10. 


Security Considerations 


MSRP traffic transported over WebSockets MUST be protected by using a 
secure WebSocket connection (using TLS [RFC5246] over TCP). 


When establishing a connection using MSRP over secure WebSockets, the 
client MUST authenticate the server using the server's certificate 
according to the WebSocket validation procedure in [RFC6455]. 


Any security considerations specific to the WebSocket protocol are 
detailed in the relevant specification [RFC6455] and are considered 
outside the scope of this document. The certificate name matching 
(described by [RFC6455]) and cryptosuite selection will be handled by 
the browser, and the browser's procedures will supersede those 
Specified in [RFC4975]. 


Since the TLS session is always terminated at the MSRP WebSocket 
Server and the WebSocket server can see the plain text, the MSRP 


client (browser) SHOULD NOT indicate end-to-end security to user. 


TLS, as used in this document, should follow the best current 
practices defined in [RFC7525]. 


IANA Considerations 
Per this specification, IANA has registered the WebSocket MSRP 
subprotocol in the "WebSocket Subprotocol Name Registry" with the 
following data: 


Subprotocol Identifier:  msrp 


Subprotocol Common Name:  WebSocket Transport for MSRP (Message 
Session Relay Protocol) 


Subprotocol Definition:  RFC 7977 


Reference:  RFC 7977 
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Appendix A. Implementation Guidelines: MSRP WebSocket Client 
Considerations 


The JavaScript stack in web browsers does not have the ability to 
discover the local transport address used for originating WebSocket 
connections. Therefore, the MSRP WebSocket Client constructs a 
domain name consisting of a random token followed by the ".invalid" 
top-level domain name, as stated in [RFC2606], and uses it within its 
From-Path headers. 


The From-Path URI provided by MSRP clients that use an MSRP relay is 
not used for routing MSRP messages, thus, it is safe to set a random 
domain in the hostpart of the From-Path URI. 
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